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A METHOD FOR HANDLING EVENT TRIGGERS AND RE- 
AUTHORIZATION TRIGGERS IN FLOW BASED CHARGING 

Field of the Technology 

[0001] The present invention relates to IP flow charging techniques, more 
particularly to a method for handling flow-based charging trigger event and re- 
authorization event. 

Background of the Invention 

[0002] Along with more and more widely employed IP flow services, how to 
charge IP flow services accurately and reasonably has brought out common attentions 
of service providers. 

[0003] Figure 1 shows a flowchart of Packet Data Protocol (PDP) Context 
activation, data transmission, and PDP Context de-activation. As shown in Figure 1, 
in General Packet Radio Service (GPRS), the process of a PDP Context activation, 
data interaction with an external Packet Data Network (PDN), and PDP Context de- 
activation comprise the following steps: 

[0004] Step 101: a mobile station (MS) sending an Activate PDP Context 
Request to a Serving GPRS Support Node (SGSN). Said Activate PDP Context 
Request carries such information as Network Layer Service Access Point Identifier 
(NSAPI), PDP type, Access Point Name (APN), required Quality of Service (QoS) 
parameter, Transaction Identifier (TI), and etc., where NSAPI which is as a 
component of the Tunnel Identifier (TID) between the SGSN and a Gateway GPRS 
Support Node (GGSN), is used for identifying a PDP Context; the type of PDP refers 
to the type of Peer-Peer Protocol (PPP), or the type of Internet Protocol (IP), or etc.; 
APN may be provided by MS to SGSN for addressing an appropriate GGSN, and said 
GGSN can determine the external network that the MS desires to access according to 
the APN, while MS provides no APN to the SGSN, the SGSN will select a default 
APN according to the subscription information of the MS; said QoS parameter refers 
to the requirement of the packet data service quality designated by the MS; and TI is 
provided to the MS for identifying a PDP Context. 
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[0005] Step 102: upon receiving the Activate PDP Context Request, SGSN 
carrying out a security check and encryption process to MS, which step is optional. 

[0006] Step 103: SGSN resolving the address information of GGSN according to 
the APN, if SGSN can resolve the address of GGSN according to the APN, it will 
create a TEID for the PDP Context. The TEED can be a combination of International 
Mobile Subscriber Identity (IMSI) and NSAPI. Then SGSN will send to GGSN a 
Create PDP Context Request. The request carries such information as PDP type, PDP 
address, APN, QoS parameter, TEID, and mode of selection, where the PDP address 
may be the IP address of the MS, which is optional and not necessarily carried by the 
Create PDP Context Request. When the PDP address is not carried by the request, in 
the subsequent process, the IP address of the MS should be assigned by GGSN or by 
the PDN which finally set up a connection with the MS. The mode of selection refers 
to the selection mode of APN, i.e. APN is selected by MS or by SGSN. If SGSN can 
not resolve the address of GGSN, SSGN will reject the Activate PDP Context Request 
sent by the MS. 

[0007] Step 104: upon receiving the Create PDP Context Request, GGSN 
determining an external PDN according to APN, and assigning a charging ID, starting 
charging, and negotiating about the QoS parameter. If GGSN can meet the 
requirements of the service quality defined by the QoS parameter, returning to SGSN 
a Create PDP Context Response, which carries such information as TEID, PDP 
address, backbone bearer protocol, negotiated QoS parameter, and charging ID. If 
GGSN can not meet the requirements of service quality defined by the QoS parameter, 
rejecting the Create PDP Context Request sent by the SGSN, and then SGSN 
rejecting the Activate PDP Context Request sent by the MS. 

[0008] Step 105: upon receiving the Create PDP Context Response, SGSN 
inserting in the PDP Context a NSAPI for identifying the PDP Context and the 
address of GGSN, and selecting the radio priority according to the negotiated QoS 
parameter, and then returning to the MS an Activate PDP Context Accept, which 
carries such information as the PDP type, PDP address, TI, negotiated QoS parameter, 
radio priority, and configuration options of PDP. Meanwhile, SGSN will start 
charging process. Upon receiving the Activate PDP Context Accept, the MS knows 
that the direct route between the MS and GGSN has been set up and the transmission 
of packet data can be carried out. 



2 



OP0544077P/US 

[0009] Step 106: the MS interacting packet data with PDN via SGSN and GGSN. 

[0010] Step 107: after completing the interaction of packet data, the MS sending 
to SGSN a De-activate PDP Context Request, which carries TI. 

[0011] Step 108: upon receiving the De-activate PDP Context Request, SGSN 
carrying out a security check and encryption process to MS, which is optional. 

[0012] Step 109~Step 111: SGSN sending to GGSN a Delete PDP Context 
Request, which carries TEED. Upon receiving the Delete PDP Context Request, 
GGSN ending the charging process for the MS, deleting the PDP Context 
corresponding to the TEED, and then sending to SGSN a Delete PDP Context 
Response, which carries TEID. Upon receiving the Delete PDP Context Response, 
SGSN ending the charging process for the MS, deleting the PDP Context 
corresponding to the TEID, and then sending to the MS a De-activate PDP Context 
Accept, which carries the TI. Upon receiving the De-activate PDP Context Accept, 
MS deleting the PDP Context corresponding to the TI. 

[0013] It can be seen from the process shown in Figure 1 that, in the current 
GPRS charging system, the starting point of charging is set at the time as the PDP 
Context is activated while the ending point thereof is set at the time as the PDP 
Context is deleted, thus charging can only be carried out according to the volume of 
the data flow transmitted in a PDP Context or according to the time duration of the 
activation of a PDP Context. In an actual network, however, after the data interaction 
between the MS and PDN, it is possible for the MS to carry out various services based 
on an activated PDP Context, i.e. if the PDN is able to provide various services, such 
as Email, WAP-based browsing, and FTP-based file transmission, etc, said various 
services provided by this PDN can be carried in an activated PDP Context after the 
MS setting up a transmission channel with said PDN. However, the service may 
provide different charging policies for different services, for example, the email 
service should be charged according to the number of the sending events and 
receiving events triggered, the WAP browsing service should be charged according to 
the volume of the data flow, and the file transmission service should also be charged 
according to the volume of the data flow, while the charging rate of the WAP 
browsing service should not be exactly the same to that of the file transmission 
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service. However, the current GPRS charging system can not carry out differentiated 
charging policies for different services bear in one PDP Context. 

[0014] Aimed at the above, the 3rd Generation Partnership Project (3GPP) is 
discussing how to implement IP Flow Based Charging (FBC). In terms of a packet 
data service, here a packet flow can be an IP flow, all the IP flows transmitted and 
received when the MS uses the service are referred to Service Data Flow, that is, the 
service data flow is a set of a plurality of IP data flows, thus IP flow based charging 
can truly reflect the amount of resources occupied by a certain service data flow. IP 
flow based charging may be considered as filtering IP flows of various services in one 
PDP Context bearers with different filters and then the IP flows picked out by 
different filters could be applied for different charging policy, respectively. Therefore, 
the charging granularity of the IP flow based charging is far smaller than the charging 
granularity of a PDP Context based charging. The granularity can be referred to the 
size of the hole of a sieve, the charging granularity of a PDP Context based charging 
means that one PDP Context is used as a hole size of the sieve, while the charging 
granularity of the IP flow based charging means that each IP service data flow is used 
as a hole size of the serve, i.e. a plurality of sieve holes are used in connection with 
one PDP Context. Thus, comparing to a PDP Context based charging, an IP flow 
based charging provides the operator or service provider with more flexible 
approaches of charging. 

[0015] The system architecture, functional specifications, and message 
interaction processes of FBC have been described in 3GPP. Fig.2A shows the 
architecture of an FBC system supporting on-line charging, where Service Control 
Point (SCP) 201 of Customized Application for Mobile Network Enhanced Logic 
(CAMEL) and Service Data Flow Based Credit Control Function (CCF) 202 
constitute an Online Charging System (OCS) 206. CCF 202 inter-works with Service 
Data Flow Based Charging Rule Function (CRF) 203 via an interface Rx, CRF 203 
inter-works with Application Function (AF) 204 via an interface Rx, CRF 203 inter- 
works with Traffic Plane Function (TPF) 205 via an interface Gx, and CCF 202 inter- 
works with TPF 205 via an interface Gy. 

[0016] The architecture of a FBC system supporting off-line charging is shown 
in Fig.2B, where CRF 203 inter-works with AF 204 via the interface Rx, CRF 203 
inter-works with TPF 205 via the interface Gx, and TPF 205 inter-works via an 
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interface Gz with Charging Gateway Function (CGF) 207 and Charging Collection 
Function (CCF) 208, respectively. 

[0017] Said TPF 205 bears an IP flow. When a bearer of the IP flow is 
established, TPF 205 will send a request for charging rule to CRF 203 via the 
interface Gx. Said charging rule request carries the information related to the user and 
MS, the bearer characteristics as well as network related information, where 
information related to the user and MS may be the international number of Mobile 
Station Integrated Service Data Network (MSISDN), or the International Mobile 
Subscriber Identity (IMSI) etc, and the information related to the network can be 
Mobile Network Code (MNC), or Mobile Country Code (MCC), or etc. In addition, 
during the transmission process of the IP flow, modifications can be made to the 
bearer, for instance, re-negotiating the QoS parameter such that the charging rule may 
be changed with different QoS parameters of the same service the user uses, e.g. the 
charging rate may be dropped with the descending of the QoS parameter. In this case, 
when modification is made to the bearer, TPF 205 may send a charging rule request to 
CRF 203 again to request a new charging rule; CRF 203 selects an appropriate 
charging rule based on the above input information provided by TPF 205, and then 
returns to TPF 205 the selected charging rule. The charging rule comprises such 
information as the charging mechanism, charging type, charging key, filter of the 
service data flow, and priority of the charging rules, where the charging mechanism is 
the mode of charging, which can be on-line charging or off-line charging; the 
charging type can be time based charging or volume based charging or time-volume 
based charging; the charging key is a parameter associated with the charging rate, i.e. 
CRF 203 may not provide TPF 205 with the charging rate directly, instead, it can 
provide TPF 205 with only a parameter associated with the charging rate. The filter of 
the service data flow is used for instructing TPF 205 which IP flow is to be filtered, 
and then TPF 205 will record the filtered IP flows according to the charging rule. The 
filter of service data based on the IP 5 tuple, which includes such information as 
source/destination IP address, source/destination port number, and protocol ID. For 
example, CRF 203 may instruct TPF 205 to filter an IP flow with the source address 
10.0.0.1, the destination address 10.0.0.2, the source/destination port number 20, and 
the protocol type TCP, and charge the filtered IP flow according to the charging rule. 
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[0018] CRF 203 can provide TPF 205 with event triggers so as to make TPF 205 
request CRF 203 for new charging rules when specific event occurs, for example, 
CRF 203 may make TPF 205 request CRF 203 for new charging rules when bearer 
modification occur. Event triggers can be deemed as events related to charging rules. 

[0019] Apart from selecting an appropriate charging rule based on the input 
information provided by TPF 205, CRF 203 can also select appropriate charging rules 
based on the input information provided by AF 204 or OCS 206, for example, AF 204 
may inform CRF 203 of the service type that the user is currently using, then CRF 
203 will select an appropriate charging rule based on said service type. 

[0020] OCS 206 consists of two functional entities, SCP 201 and Service Data 
Flow Based Credit Control Function (CCF) 202, where CCF 202 is the functional 
entity for credit control and is only used in an on-line charging system, which can be 
realized by adding new functions to the existing OCS 206. In the process of on-line 
charging, CCF 202 manages and controls the users' credits, when the user uses the 
service, CCF 202 authorizes the credits in the credit pool of the user, and sends to 
TPF 205 via the interface Gy the credits available to the user. 

[0021] In addition, OCS 206 may require TPF 205 to request re-authorisation of 
the credit when re-authorization triggers occur. After that, OCS 206 will re-authorize 
the user based on the corresponding re-authorization triggers reported by TPF 205 and 
may possibly re-calculate the user's credits. For example, when the user's credits 
provided to TPF 205 by OCS 206 have been run out, TPF 205, according to the 
detection of credit authorization lifetime expiry, which matches the re-authorization 
triggers, needs to report to OCS 206 the credit authorization lifetime expiry event is 
occurred; and then OCS 206 re-calculates the credits available to the user according to 
the balance of the user's account. For another example, when area based charging 
policy is applied, OCS 206 determines the charging rate according to the current 
location of the user and calculates the user's credits based on the charging rate; when 
the user moves to another location, if SGSN changes, TPF 205, according to the 
detection of SGSN change, which matches the re-authorization triggers, the TPF 
reports to OCS 206 the SGSN change event is occurred, and the OCS re-determines 
the charging rate based on the updated current location of the user and recalculates the 
user's credits. For yet another example, OCS determines the charging rate based on 
the current QoS parameter of the service used by the user, when the QoS parameter is 
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modified, TPF, according to the bearer modification, which matches the re- 
authorization triggers, needs to report to OCS 206 the bearer modification event is 
occurred, and OCS 206 then determines the charging rate based on the modified QoS 
parameter and re-calculates the user's credits. 

[0022] In a GPRS network, TPF 205 refers to GGSN, AF refers to a service 
gateway or a service server in the PDN and CRF 203 refers to a newly-added logic 
entity. TPF 205 is the performing point of charging rules, while CRF 203 is the 
controlling point of charging rules. 

[0023] So far, 3GPP has defined the process of performing a charging rule 
request by the occurrence of an event trigger while charging on-line when the bearer 
is modified, i.e. the process of TPF requesting a charging rule from CRF at the 
occurrence of an event trigger, as shown in Figure 3: 

[0024] Step 301: a User Equipment (UE) sends a Modify Bearer Service Request 
to TPF. In a GPRS network, it equivalents to that GGSN receives an Update PDP 
Context Request. 

[0025] Step 302: upon receiving the Modify Bearer Service Request, TPF 
compares the Modify Bearer event with the pre-stored event triggers, if these two 
match, proceed to step 303; otherwise, continue to monitor the occurrences of event 
triggers. 

[0026] Step 303: TPF sends to CRF a Request Charging Rules, which carries the 
relevant input information for charging rule selection. 

[0027] Step 304~step 305: upon receiving the Request Charging Rules, CRF 
selects an appropriate charging rule basing on the available information to the CRF 
(e.g. information may be available from the AF and the information received from the 
TPF)., and then returns to TPF a Provision Charging Rules, which carries the selected 
charging rule and the actions thereof. 

[0028] Step 306: upon receiving the Provision Charging Rules, TPF performs the 
related charging rule actions on the charging rule selected by CRF, i.e. the charging 
rules may need to be installed, and/or removed, and/or modified. 

[0029] Step 307: TPF returns to the UE a Modify Bearer Service Accept, and 
continues with the subsequent process of bearer modification. 



7 



OP0544077P/US 

[0030] While on-line charging, bearer modifications will trigger a re- 
authorization process, i.e. TPF will ask OCS to re-authorize the credit of the user, the 
specific implementation of which is shown in Figure 4: 

[0031] Step 401: a UE sends a Modify Bearer Service Request to TPF. In a 
GPRS network, it equivalents to that GGSN receives an Update PDP Context Request. 

[0032] Step 402: upon receiving the Modify Bearer Service Request, TPF 
compares the Modify Bearer event with the pre-stored re-authorization triggers, if 
these two match, proceed to step 403; otherwise, continue to monitor the occurrence 
of re-authorization triggers. 

[0033] Step 403: TPF sends to OCS a Credit Control Request, which carries the 
balance of the user's credits and information related to the charging rule, requesting 
OCS to re-calculate the credits of the user. The information related to the charging 
rule provided by TPF for OCS may come from CRF. 

[0034] Step 404: upon receiving the Credit Control Request, OCS re-calculates 
the credits of the user and then returns to TPF a Credit Control Answer. If OCS 
obtains by calculating the user's credits, the Credit Control Answer will carry the 
user's credits re -calculated by OCS; if OCS fails to calculate the user's credits, the 
Credit Control Answer may carry the error cause value. 

[0035] Step 405: upon receiving the Credit Control Answer, TPF returns to the 
UE a Modify Bearer Service Accept. If the Credit control Answer carries the user's 
credits, TPF will accept the Modify Bearer Service Request sent by the UE and 
continue with the subsequent process of bearer modification; if the Credit Control 
Answer carries no user's credits, TPF will reject the Modify Bearer Service Request 
sent by the UE. 

[0036] At present, there are descriptions made on the charging mode in which 
CRF controls the bearer event occurred in TPF by means of providing the event- 
trigger to the TPF in the specifications, i.e. TPF reports to CRF after detecting the 
occurrence of an event trigger, CRF learns that the bearer has modified by the event 
trigger reported by TPF and then selects an appropriate charging rule and sends the 
charging rule to TPF. The event triggers defined in the specifications may include 
PLMN change event, QoS change event, RAT (Radio Access Technique) type change 
event, and TFT (Transmission Flow Template) change event. 
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[0037] In addition, there are descriptions made on how OCS controls the credit 
consumed in TPF by means of providing re-authorization triggers to the TPF in the 
specifications, i.e. TPF reports to OCS after detecting the occurrence of re- 
authorization triggers, OCS learns the consumed credit of the user and the 
modification of the bearer according to the re-authorization trigger reported by TPF, 
and re-calculates the user's credits and sends the credits to TPF. The re-authorization 
triggers defined in the specifications may include credit authorization lifetime expiry 
event, idle timeout event, charging rule change event, as well as some GPRS events, 
such as SGSN change event, QoS change event, and RAT type change event. 

[0038] It can be seen from the above descriptions that both event triggers and re- 
authorization triggers include bearer events, such as SGSN change, QoS parameter 
change, and RAT type change. Thus, when a certain bearer event trigger occurs, TPF 
will match this bearer event with both event triggers and re-authorization triggers, 
accordingly, it is necessary to report this bearer event to CRF and OCS, respectively. 

[0039] In case that TPF first reports a re-authorization trigger to OCS, and then 
reports an event trigger to CRF, as it is possible for CRF selecting a new charging rule 
according to the received event trigger and sending the newly selected charging rule 
to TPF, the newly selected charging rule issued to TPF by CRF is likely to match the 
charging rule event in the re-authorization triggers, which will re-trigger a re- 
authorization process, making the first re-authorization process redundant and wasting 
the interface resources between TPF and OCS in an FBC system. 

* 

Summary of the Invention 

[0040] In view of the above, the present invention is to provide a method for 
handling event triggers and re-authorization triggers in flow based charging so as to 
improve the re-authorization process in flow based charging. 

[0041] The method comprising the following steps: 

[0042] (A) TPF determining whether the bearer event matches an event trigger, 
if it matches, proceeding to step B, and otherwise, proceeding to step C; 

[0043] (B) TPF requesting the charging rules from CRF; 
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[0044] (C) TPF determining whether the bearer event matches a re-authorization 
trigger, if it matches, the TPF performing a re-authorization process, and otherwise, 
ending the current process. 

[0045] In accordance with the method disclosed by the present invention, when a 
bearer event occurs, TPF first estimates whether the occurred bearer event matches an 
event trigger, if it matches, reports the occurred event trigger to CRF; then estimates 
whether the occurred bearer event matches a re-authorization trigger, if it matches, 
reports the re-authorization trigger to OCS and continues with the subsequent re- 
authorization process. In this way, only one interaction for re-authorization is needed 
between TPF and OCS, which optimizes the re-authorization process when there is 
overlap between the event triggers and re-authorization triggers and improves the re- 
authorization process in flow based charging. 

Brief Description of the Drawings 

[0046] Figure 1 shows a flowchart of a PDP Context activation, data interaction, 
and PDP Context de-activation process; 

[0047] Figure 2A shows the architecture of an FBC system supporting on-line 
charging; 

[0048] Figure 2B shows the architecture of an FBC system supporting off-line 
charging; 

[0049] Figure 3 shows the flowchart of triggering TPF sending a request to CRF 
for a charging rule by an event trigger in the prior art; 

[0050] Figure 4 shows the flowchart of triggering TPF sending a request to OCS 
for re-authorization by a re-authorization trigger in the prior art; 

[0051] Figure 5 shows the flowchart of handling event triggers and re- 
authorization triggers in accordance with one preferred embodiment of the present 
invention; 

[0052] Figure 6 is a schematic diagram illustrating the message interaction in the 
process of handling event triggers and re-authorization triggers in accordance with the 
preferred embodiment of the present invention. 
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Detailed Description of the Invention 

[0053] In order to make the object, solution and merits of the present invention 
clearer, the preferred embodiments of the present invention are hereinafter described 
in more detail with reference to the accompanying drawings. 

[0054] In accordance with the preferred embodiments of the present invention, 
when a bearer event occurs, TPF first determines whether the bearer event occurred 
matches an event trigger, if it matches, requesting the charging rules from CRF; then 
TPF decides whether the occurred bearer event matches a re-authorization trigger, if it 
matches, the TPF performing a re-authorization process. In this way, only one 
interaction for re-authorization is needed between TPF and OCS, which optimizes the 
re- authorization process when there is overlap between event triggers and re- 
authorization triggers. 

[0055] Figure 5 shows the flowchart in accordance with a preferred embodiment 
of the present invention for handling event triggers and re-authorization triggers. As 
shown in Figure 5, the process of handling event triggers and re-authorization triggers 
comprises the following steps: 

[0056] Steps 501-502: TPF detects the occurrence of a bearer event and 
determines whether the occurred bearer event matches an event trigger, if it matches, 
proceed to step 503; otherwise proceed to step 507. 

[0057] Step 503: TPF requests the charging rules from CRF, i.e. TPF provides 
CRF with the input information for selecting a charging rule, and further provides 
CRF with the bearer event currently occurred so as to inform CRF of the event trigger 
currently triggered the charging rule request process and request CRF to provide a 
charging rule; upon receiving the charging rule request, CRF selects a charging rule 
according to the input information and bearer event provided, and provides TPF with 
the selected charging rule and actions thereof. After receiving the charging rule 
provided, TPF performs the related charging rule actions on the charging rule selected 
by CRF. 

[0058] Step 504: TPF determines whether the charging rule provided by CRF 
changes, if it does, proceed to step 505; otherwise, proceed to step 507. 
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[0059] Step 505: TPF determines whether a re-authorization is needed due to the 
changed charging rule, if it is, proceed to step 506; otherwise, proceed to step 507. 

[0060] Step 506: TPF determines whether the bearer event currently occurred 
matches a re-authorization trigger, if it matches, proceed to step 508; otherwise, 
proceed to step 509. 

[0061] Step 507: TPF determines whether the bearer event currently occurred 
matches a re-authorization trigger, if it matches, proceed to step 508; otherwise, end 
the current process. 

[0062] Step 508: TPF performs a re-authorization process, i.e. TPF provides 
OCS with the information about the balance of the user's credits and the related 
charging rule, requests OCS to re-calculate the user's credits, and further provides 
OCS with the bearer event currently occurred to inform OCS of the re-authorization 
trigger that triggers the re-authorization process; and then OCS provides TPF with the 
re-calculated user's credits, and then ends the current process. 

[0063] Step 509: TPF performs a re-authorization process, i.e. TPF provides 
OCS with the information about the balance of the user's credits and the related 
charging rule, and requests OCS to re-calculate the user's credits, and then OCS 
provides TPF with the re-calculated user's credits. 

[0064] Step 506 may also be performed at any time between step 501 -step 505, 
so long as TPF determines that the bearer event currently occurred matches a re- 
authorization trigger, TPF will, when performing a re-authorization process in the 
subsequent step 508, further provide OCS with the event currently occurred, in order 
to inform OCS the detected re-authorization trigger. 

[0065] Figure 6 is a schematic diagram illustrating the message interaction in the 
process of handling event triggers and re-authorization triggers in accordance with the 
preferred embodiment of the present invention. As shown in Figure 6, the message 
interaction in the process of handling event triggers and re-authorization triggers 
comprises the following steps: 

[0066] Step 601 is the same with step 301. 
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[0067] Step 602: upon receiving the Modify Bearer Service Request, TPF 
compares the bearer modification event currently occurred with the pre-stored event 
triggers, if they match, proceed to step 603; otherwise, go directly to step 608. 

[0068] When a bearer is set up, the specific process of implementation is as 
follows: while charging on-line, when a bearer is set up, TPF sends to CRF a charging 
rule request, which carries the input information about the charging rule, such as the 
information of UE, bearer characteristics, information of the network and etc.; CRF 
selects an appropriate charging rule according to the received input information, and 
furthermore, based on the input information provided by TPF, determines the event 
triggers to be monitored by TPF, and then sends the charging rule and event triggers 
to TPF. 

[0069] In addition, when a bearer is modified, CRF may also provide TPF with 
the event triggers to be monitored by TPF, i.e. when an event trigger occurs, TPF will 
report to CRF the occurred event trigger; upon receiving the event trigger reported by 
TPF, CRF may continue to issue new event triggers. When CRF receives the input 
information provided by external entities, such as AF and OCS, CRF may provide 
TPF as well with the event triggers to be monitored by TPF, i.e. CRF may unsolicited 
provide event triggers to TPF. 

[0070] Upon receiving the charging rule and event triggers provided by CRF, 
TPF monitors the occurrence of event triggers, filters the appropriate IP flows 
according to the filter of the charging rule, and then charges the filtered IP flows using 
said appropriate charging rule. 

[0071] OCS may directly provide TPF with the re-authorization triggers which 
TPF is required to monitor. For example, in the authorization process, TPF sends to 
CRF a Credit Request; upon receiving the Credit Request, OCS calculates the user's 
request and returns to TPF a Credit Answer, which may further carry the re- 
authorization triggers in addition to the user's credits, and TPF is required to monitor 
the re-authorization triggers, i.e. when the re-authorization trigger occurs, TPF will 
report to OCS the re-authorization trigger currently occurred. OCS may also provide 
re-authorization triggers to TPF via CRF. 

[0072] In addition, when a re-authorization trigger occurs, TPF will report to 
OCS the re-authorization trigger currently occurred; after receiving the re- 
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authorization trigger reported by TPF, OCS may again provide new re-authorization 
triggers to TPF. 

[0073] Step 603: TPF sends to CRF a Charging Rule Request, which carries the 
input information provided for CRF to determine the charging rule, and which may 
further carries the related bearer event currently occurred to inform CRF of the event 
trigger that triggers the current charging rule request process. 

[0074] Step 604~Step 606 are the same with step 304~step 306. 

[0075] Step 607: TPF determines whether the charging rule provided by CRF has 
been changed, if the rule has been changed, further determines whether a re- 
authorization is needed due to the changed charging rule, if it is, continue with step 
608; if the charging rule has been not changed or the a re-authorization is not needed 
due to the changed charging rule,, proceed to step 608. 

[0076] Step 608: TPF compares the bearer modification event currently occurred 
with the pre-stored re-authorization triggers, if they match, proceed to step 609; 
otherwise, TPF continues to determines whether there is the need for performing a re- 
authorization process determined in step 607, if there is the need, proceed to step 609, 
if there is no need, go directly to step 611. 

[0077] Step 609: TPF sends to OCS a Credit Request, which carries the 
information of the balance of the user's credits and the relevant charging rule, 
requesting OCS to re-calculate the user's credits. If it is decided in step 607 that there 
is the need for performing a re-authorization process, the Credit Request sent by TPF 
to OCS may further carry the information on the modified charging rule. In addition, 
if it is decided in step 608 that there is the need for performing a re-authorization 
process, the Credit Request sent by TPF to OCS may further provide the modified 
bearer information of the bearer modification event. 

[0078] Step 610: upon receiving the Credit Request, OCS re-calculates the user's 
credits, and then returns to TPF a Credit Answer, if OCS obtains by calculation the 
user's credits, the Credit Answer will carry the user's credits re -calculated by OCS; if 
OCS fails to calculate the user's credits, the Credit Answer will carry the error cause 
value. 

[0079] Step 611: TPF returns to the UE a Modify Bearer Service Response and 
determines according to the result of the above processing whether to accept the 
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Modify Bearer Service Request, if it is determined to accept the request, continue 
with the subsequent bearer modification process; otherwise, reject the bearer 
modification request. For example, if the Credit Answer carries the user's credits, 
TPF will accept the Modify Bearer Service Request sent by the user and continue with 
the subsequent bearer modification process; if the Credit Answer carries no user's 
credits, TPF will reject the Modify Bearer Service Request sent by the user. 

[0080] In the above process, in step 607, when TPF determines there is change in 
the charging rule, and the charging rule change event requires performing a re- 
authorization process, go directly to step 609 without performing step 608. 

[0081] To sum up, the foregoing description is only a preferred embodiment of 
the present invention and not to be construed as limiting the scope thereof. 
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